Only 3 of 18 CI jobs used Blacksmith; the rest sat on ubuntu-latest, including the four slowest remaining jobs (the Confidence-fast shards at 8m/8m/6m/5m) which dominate the ~9 min critical path.

FIG-518 had this deferred on two claims from 2026-07-21 — that blacksmith-4vcpu was unprovisioned for this org, and that supply arrived in unpredictable bursts. Both were re-tested empirically and are no longer true. An unprovisioned label queues forever rather than erroring, so this had to be measured: a probe ran one job on every size, all five concurrently in a single matrix, and all were allocated within 9–10 seconds with correct cores/memory (2/7Gi, 4/15Gi, 8/30Gi, 16/62Gi, 32/113Gi). Tiered sizing is therefore available, which the old "16vcpu or nothing" constraint ruled out.

Sizing

Deliberately NOT migrated

sim-unit-perf-guards and perf.yml stay on ubuntu-latest. They enforce scripts/perf_guard_budgets.json, which is calibrated to that machine class — moving them would not merely make them faster, it would make every budget pass trivially and hide real regressions. Those budgets were just found to have been ungated for two days (PR #128); silently invalidating them again would repeat the same failure. It is kept on ubuntu via a per-matrix-entry runner value rather than splitting the job, so no job or matrix name changes — the ~20 required check names are byte-identical, so no required gate can be silently dropped.

cross-check is untouched (matrix includes macOS; no Blacksmith darwin).

Runner behaviour is only provable in CI. Per FIG-518's second hard-won rule, this wants observing under concurrent runs (a main merge overlapping an open PR) before being called good — a single uncontended green run measures machine speed, not whether CI works.